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Abstract —Dit document is het resultaat van een onderzoek 
naar de implementatie van objecten op run-time niveau van ETH 
Oberon-2, dit op het Windows platform. 

Index Terms —Oberon, Object, pointers, run-time 

I. INLEIDING 

D IT is het resultaat van een uitgebreid onderzoek naar de 
effectieve run-time implementatie van de taal Oberon op 
het Windows platform. 

Oberon is een programmeertaal dat de gebruiker mogelijk 
maakt om programma’s te schrijven die allerlei zaken kunnen 
uitvoeren voor hen. Dit gaat van simpele berekeningen tot 
ingewikkelde programma’s en grafische software met 3 
dimensionale mogelijkheden. Oberon, dat sinds eindjaren ’80 
bestaat is nooit een veel gebruikte taal geworden, ondanks het 
volledig gratis is Vele programmeurs houden zich aan C, 
C++, Pascal, Basic, Java of een andere programmeertaal. Het 
is echter zo dat Oberon toch veel kan en best bruikbaar is, 
zeker en vast voor educatieve doeleinden om studenten te 
laten leren hoe alles in elkaar zit. Zo wordt het ook 
wereldwijd in verschillende universiteiten gebruikt. Oberon 
heeft hier het voordeel dat het heel weinig functies heeft 
meegekregen, zodat eigenlijk alles door de student zelf moet 
worden gemaakt. Bovendien is er weinig documentatie te 
vinden waardoor men de student verplicht het zelf te zoeken 
en het werk niet door andere mensen te laten maken. Deze 
twee laatst opgenoemde eigenschappen van Oberon maken 
uiteraard de taal niet geliefd voor de professionele 
programmeur. 

Door dit document maken we het verdere onderzoek naar 
Oberon beter mogelijk doordat de onderzoeker meer 
documentatie heeft om met te starten. 


II. Objecten 

Iedere programmeur die een beter programma schrijft kent 
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een object en maakt er gebruik van. Het schrijven van een 
programma zonder dat hier enig object in wordt gebruikt en 
dat toch een veelzijdig, krachtig en gebruiksvriendelijk 
programma is komt weinig voor. Een object is een instantie 
van een klasse en in Oberon worden klassen voorgesteld als 
records, waarbij de pointer die verwijst naar dat record wordt 
aangeduid als een object. Object georiënteerd werken maakt 
het mogelijk dat de analyse en het ontwerp van de software 
rond de datastructuren ligt en gebruikt wordt en niet 
andersom: de software rond de verwerking en in tweede 
instantie de datastructuren. Zeker voor het gebruik van 
zogenaamde ADT’s (Abstract Data Type) is dit bijna 
onmogelijk om geen gebruik te maken van object georiënteerd 
te werken. Door gebruik te maken van type-extensie kan men 
een bestaand record uitbreiden tot een gedetailleerdere 
beschrijving, inheritance of ook overerving genoemd. 
Overerving omdat men alles overneemt wat ervoor inzat, plus 
de nieuwe opgegeven records. Een andere methode om meer 
te doen met objecten is door procedures hieraan te verbinden, 
deze procedures worden in vaktermen aangeduid als type- 
bound procedures, omdat ze gebonden zijn aan een bepaald 
(data)type. 

Het object bestaat meestal uit een record. Voorbeeld in 
Oberon code: 

TYPE 

Object* = POINTER TO ObjectDesc; 

ObjectDesc* = 

RECORD 
i*: INTEGER; 
i2*: INTEGER; 
next: Object; 

END; 

Bij dit voorbeeld zie je dat het object een pointer is, dat 
verwijst naar het record. In het record zelf is er een “next” 
aanduiding die opnieuw wijst naar een pointer, die op zijn 
beurt wijst naar een nieuw record. 

Dit vertelt al hoe de implementatie zal zijn van dit object, 
het is met behulp van pointers. Meer weten we echter niet en 
hiervoor moeten we gaan kijken op het run-time niveau. 

Het achterhalen van deze implementatie is echter niet zo 
eenvoudig zoals het lijkt. De onderzoeker moet namelijk zelf 
programmacode gaan schrijven in low-level niveau, op het 
laagste niveau dat je kan schrijven in Oberon. Je hebt 
hierdoor directe toegang tot adressen, bits, geheugenplaatsen 
en registers. Verder maakt dit echter wel dat je 
platformafhankelijk bent. Daarom onderzoeken we hier ook 
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enkel de implementatie op het Windows platform. Voor 
andere platformen, zoals Linux of Macintosh, zal dit anders 
zijn. 

Het object dat als voorbeeld werd gegeven kan verder in 
dezelfde module worden gebruikt als volgt: 

PROCEDURE (s: Object) Opslaan*(getal: INTEGER); 

BEGIN 

s.i := getal; 

END Opslaan; 

Dit zal het mogelijk maken dat er een getal wordt 
opgeslagen in de variabele i die een integer is. Om dit 
programma effectief te laten werken hebben we een andere 
module nodig die gebruik maakt van dit ADT: 

IMPORT ResearchObject, In, OutExt; 

VAR 

object: ResearchObject.Object; 

PROCEDURE Opslaan*; 

VAR 

getal: INTEGER; 

BEGIN 

In. Open; 

In.Int(getal); 

NEW(object); 

object.Opslaan(getal); 

END Opslaan; 

Hierin zie je dat de module “ResearchObject” wordt 
geïmporteerd en er vervolgens gebruik wordt gemaakt van het 
object om een getal in te lezen en het vervolgens weg te 
schrijven. 

Wat we nu onderzoeken is hoe dit object in het geheugen 
op run-time niveau wordt behandeld. Er zijn vele eisen: het 
moet zo weinig mogelijk geheugen gebruiken, het moet snel 
toegankelijk zijn en er moet snel en eenvoudig operaties op 
worden uitgevoerd. Bovendien moet er door de “garbage 
collector” worden toegezien om informatie waar niets meer 
naar verwijst te laten verwijderen (veroorzaakt doordat in het 
programma een pointer op NIL wordt gezet of naar een andere 
locatie moet wijzen waardoor het onmogelijk is om nog aan 
het stukje geheugen te geraken, zodat het door de garbage 
collector kan worden “opgeruimd”). Deze zaken maken dat 
het niet zo eenvoudig is zoals het op het eerste zicht lijkt. 

III. De run-time implementatie onderzocht 

Het eerste wat onderzocht werd is hoe in Oberon de pointer 
naar het object wordt geplaatst. Als we in Oberon het object 
enkel declareren dan is de pointer, het adres naar het object 
leeg: NIL. Indien we in Oberon de instructie NEW(object); 
laten uitvoeren, dan wordt er in het geheugen (de heap) een 
plaats voorzien, waar het adres komt naar het object. 
Wanneer we het adres opvragen van het object, krijgen we 
bijvoorbeeld de LONGINT 15333312 terug (origineel is dit 
een bitsequentie, die voor de leesbaarheid werd omgezet naar 
een tiendelig getal). Wanneer we echter in de programmacode 


opnieuw een NEW(object); laten uitvoeren, zien we dat 
Oberon verwijst naar exact dezelfde geheugenplaats, in dit 
geval dus opnieuw 15333312. Hieruit besluiten we dat 
Oberon steeds vooraan het geheugen begint te verdelen. 
Indien we het object vrijgeven en onmiddellijk opnieuw een 
adres aanmaken (dus door NEW), dan gaat Oberon dezelfde 
plaats teruggeven. Deze stelling bewijzen we door gebruik te 
maken van een tweede object. Indien we eerst objectl 
aanmaakten, vervolgens object2 aanmaakten en opnieuw 
objectl, dan had in beide gevallen objectl hetzelfde adres. 
Dit is zo omdat op het ogenblik dat we NEW() doen van 
objectl, die plaats vrijkomt. Onmiddellijk kan Oberon dan 
dezelfde plaats teruggeven om de NEW() uit te voeren. 

Het tweede wat onderzocht werd is hoe Oberon omspringt 
met het verdelen van de velden in het record zelf. We hebben 
in ons voorbeeld object 3 velden in ons record: i, i2 en next. 
De eerste twee zijn een integer en de derde is een pointer. 
Hieronder ziet u een overzicht van de verschillende outputs: 
Adres object: 15333312 
Adres i: 3282368 
Adres i2: 3282370 
Adres next: 3282372 


Adres object: 15333312 
Adres i: 3586688 
Adres i2: 3586690 
Adres next: 3586692 


Adres object: 15333312 
Adres i: 3705312 
Adres i2: 3705314 
Adres next: 3705316 


Adres object: 15333312 
Adres i: 9362208 
Adres i2: 9362210 
Adres next: 9362212 


Adres object: 15333312 
Adres i: 26409920 
Adres i2: 26409922 
Adres next: 26409924 

Wanneer we onderzoeken of hier enige logica in zit met het 
toekennen van de geheugenplaats (en dus te zien aan het 
geheugenadres) komen we tot de volgende conclusie. Er is 
geen relatie tussen de adressen die Oberon geeft aan i, i2 en 
next bij elke NEW() die we deden. Waar wel een relatie is 
tussen i, i2 en next zelf bij een bepaalde toewijzing van de 
adressen. Laat ons de eerste reeks van adressen bekijken: het 
adres van i is daar 3282368, het adres van i2 is 3282370 en 
het adres van de next pointer is 3282372. Hier is steeds een 
verschil van 2. Dit klopt omdat er wordt gewerkt met byte 
adressering. Men werkt in Oberon (Windows) met het 
systeem dat men het geheugen gaat indelen per 8 bits, samen 
in 1 byte. Men geeft vervolgens enkel een adres aan elke 
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byte. Dit is een voordeel doordat men minder grote adressen 
kan gebruiken voor het aangeven van geheugenplaatsen, maar 
heeft het nadeel dat informatie ook in een volledige byte moet 
worden opgeslagen. Zo zal een boolean die toch maar 1 bit 
nodig heeft, toch in het geheugen 8 bits gebruiken omdat het 
een byte adressering is. Een integer is in Oberon 16-bit ofwel 
2 bytes. Hier zie je onmiddellijk de verklaring waarom er 
tussen de adressen i, i2 en next 2 bytes tussen zit. Oberon 
gaat namelijk de toekenning van het geheugen sequentieel 
uitvoeren. 

Het derde wat vrijwel rechtstreeks volgt uit het vorige is dat 
Oberon ook alles in volgorde gaat toekennen zoals het in het 
record wordt aangegeven. Als i en daaronder i2 staat, gaat 
eerst i in het geheugen staan, en dan pas i2. Oberon gaat dus 
zelf niet kijken wat mogelijk het meest efficiënte is en zo bv. 
een array pas later toekennen dan een integer. Voorbeeld: 

ObjectDesc* = 

RECORD 
i*: INTEGER; 
x: ARRAY 100 OF REAL; 
i2*: INTEGER; 
y: ARRAY 100 OF REAL; 
z: POINTER TO Object2; 
a: REAL; 
next: Object; 

END; 

Is mogelijk minder efficiënt als de volgende: 

ObjectDesc* = 

RECORD 
i*: INTEGER; 
i2*: INTEGER; 
a: REAL; 

x: ARRAY 100 OF REAL; 
y: ARRAY 100 OF REAL; 
z: POINTER TO Object2; 
next: Object; 

END; 

Bij de laatste zijn namelijk de integers, de arrays en de 
pointers gegroepeerd bij elkaar, wat voor de 
geheugenaanvraag en toekenning mogelijk efficiënter kan 
werken. Voor het gebruik in het verdere programma 
veranderd er echter totaal niets; waardoor Oberon dit 
efficiënter zou kunnen doen op de achtergrond zonder 
medeweten van de programmeur. 

Deze laatste kennis is echter eenvoudig bruikbaar om na te 
gaan hoeveel bits bepaalde types vragen. Zo kan je nagaan 
dat een pointer 32-bit vraagt, ofwel 4 bytes, door in ons 
voorbeeld met i, i2 en next ook nog achter de next 
bijvoorbeeld nog een integer te laten aanmaken en zo het 
adres te zien dat er 4 bytes verder is gesprongen. 

Als vierde onderzoeken we hoe de implementatie is van de 
items in de records zelf. Hier ontdekken we dat deze gewoon 
worden opgeslagen zoals ze zouden worden opgeslagen als ze 
een gewone variabele zouden zijn. Een INTEGER wordt 
opgeslagen als een INTEGER, een REAL als een REAL, enz. 
Er worden dus geen speciale technieken gebruikt om 


efficiënter de gegevens op te slaan, te verdelen, enz. 
Als we bijvoorbeeld het getal 7859 laten opslaan in de integer 
i en we gaan vervolgens de bits ophalen die op het adres staan 
in het geheugen wat we hebben onderzocht, dan krijgen we de 
volgende bitsequentie inhoud: 00011110. Dit is echter het 
getal 30. Maar we hebben gezegd dat een integer werd 
opgeslagen als 16-bit ofwel 2 bytes. We hebben tot nu toe 
nog maar 1 byte ofwel 8 bit opgehaald en we moeten dus ook 
het adres+1 ophalen. De bitsequentie die zich bevindt op dit 
adres is 10110011. De twee achter elkaar plaatsen: 
0001111010110011 geeft inderdaad uitgerekend naar het 
tiendelige stelsel het getal 7859, zoals we hadden gevraagd 
om op te slaan. 

Het vijfde wat werd onderzocht is wat Oberon doet indien 
er een variabele (maar meer specifiek een onderdeel van een 
record in een object) wordt aangemaakt, wat Oberon dan doet. 
We maken dus een nieuw object aan, in ons voorbeeld worden 
dan ook onmiddellijk de i, i2 en next aangemaakt. Wat we 
echter tot nu toe niet weten is wat de inhoud van deze i, i2 en 
next is indien we deze zelf nog niet hebben opgegeven. Om 
dit te onderzoeken laten we een NEW(object) starten en 
vervolgens vragen we de bit inhoud van de integer i op. Wat 
we terug krijgen is 0000000000000000. Met andere woorden 
0. Oberon gaat dus de plaats in het geheugen steeds 
leegmaken en dus zetten naar nul. Op het eerste zicht lijkt dit 
normaal: je hebt nog niets met de variabele gedaan en dus 
moet ze leeg zijn. Maar als je beter nadenkt is dit niet zo. Er 
wordt geheugen toegewezen waar reeds iets kan instaan, 
Oberon moet dus specifiek elke bit naar 0 zetten, wat niet alle 
andere programmeertalen of compilers doen. 

Het volgende wat werd onderzocht is de connectie tussen 
het adres van het object zelf en haar elementen. Hier was 
steeds een groot verschil in: 

Adres object: 15333312 
Adres i: 9362208 
Adres i2: 9362210 
Adres next: 9362212 

Dit verklaard echter duidelijk hoe de structuur verder in 
elkaar zit. Het totale geheugen moet worden verdeeld voor 
verschillende programma’s. Dit doet het besturingssysteem, 
in ons geval Windows. Oberon krijgt een stuk geheugen 
toegewezen waar het kan in werken. Vervolgens gaat Oberon 
zichzelf organiseren om dit geheugen goed te kunnen 
gebruiken. Het totale geheugen wordt verdeeld in 3 grote 
stukken. Het eerste onderdeel is het geheugen voor het 
programma zelf: Oberon en het gemaakte programma door de 
programmeur. Dit zijn dus alle instructies die moeten worden 
gevolgd en die de processor zal uitvoeren. De tweede grote 
blok is een structuur waarmee wordt gewerkt. Deze bevat 
onder andere de pointers naar objecten en de lijst van het 
object zelf. Zo houdt Oberon buiten de gegevens dat er i, i2 
en next aanwezig is in het record ook nog andere zaken bij: 
het aantal componenten en vervolgens van elk stuk van de 
record (bij ons, i, i2, next) de naam (dus i, i2,...), het type 
(INTEGER, POINTER, enz) en de locatie hiervan die een 
pointer is naar het adres. Alle onzichtbare gegevens voor de 
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programmeur staan in de zogenaamde type-descriptor. Zo zal 
het geheugen bv. het volgende bevatten voor ons object dat 
een record is van i, i2 en next: 

# componenten: 3 
Label 1: i 

Type 1: INTEGER 
Locatie 1: 9362208 
Label 2: i2 
Type 2: INTEGER 
Locatie 2: 9362210 
Label 3: next 
Type 3: POINTER 
Locatie 3: 9362212 

Via een testprogramma is een stuk van de bitsequentie de 


volgende 

van 


een 

record: 

00001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 

11001110 

10011110 

10000000 

00100100 


11001110 10011110 10000000 00100100 11001110 

Deze bevat de informatie zoals hierboven aangeduid in 
binaire gegevens. 

Deze informatie wordt achter elkaar in het geheugen 
opgeslagen. Eerst de type-tag die een pointer is naar de plaats 
van de informatie van de type-descriptor, vervolgens de 
pointer naar het object. Ook de type-descriptor staat ergens 
anders opgeslagen in het geheugen omdat deze moet kunnen 
wijzigen door type-extensie. Intern gezien kan je dus met een 
procedure P van het record t met T als type op volgende 
manier worden opgeroepen: t A .tag A .procedureTabel[indexP]. 

Als het programma toegang wilt krijgen tot het object kan 
de computer zo onmiddellijk zien wat in het programma met 
“next” bedoeld wordt, dat het een pointer is en onmiddellijk 
ook de locatie waar de informatie staat opgeslagen in het 
geheugen. Dit maakt een snelle toegang mogelijk. 

Het derde onderdeel van het geheugen is een structuur voor 
de data zelf. Dit is een stuk geheugen waar de effectieve 
informatie van de arrays, integers, enz. wordt opgeslagen. Dit 
is allemaal achter elkaar en de computer weet welk stuk hij 
eruit moet halen dankzij de gegevens van het vorige 
onderdeel: daar staat in dat het bijvoorbeeld een integer is, en 
dus 32-bits moet nemen. 

De drie onderdelen zijn ook van elkaar gescheiden en lopen 
niet door elkaar, wat logisch lijkt. Indien alles door elkaar zou 
lopen is het verdelen in 3 onderdelen niet echt nuttig. Om dit 
extra te bewijzen kan je eenvoudig kijken naar de adressen. 
In ons voorbeeld heeft het object het adres 15333312 en de 
integer i het adres 9362208, de andere (i2, next,...) komen er 
vlak achter. Deze twee adressen liggen enorm ver uit elkaar 
(om exact te zijn in dit geval 5.971.104 bytes). 

Door het gebruik van deze opslag en door het gebruik van 
onzichtbare informatie (voor de programmeur) kan onder 


andere ook de “garbage collector” zijn werk doen. Indien er 
een pointer verdwijnt naar een bepaald adres, dan kan de 
“garbage collector” dit wissen en terug vrijstellen voor een 
volgende vraag naar geheugen. 

De keuze om de informatie gelinkt op te slaan is het 
krachtigste en heeft de meeste mogelijkheden. Dit maakt het 
mogelijk dat de data die wordt opgeslagen eenvoudig kan 
uitbreiden en terug kan krimpen. Het is echter minder 
efficiënt op gebied van geheugengebruik omdat we veel 
informatie moeten opslaan voor we aan de effectieve data 
kunnen geraken: we slaan de datastructuur en de data apart op, 
waardoor er overal pointers moeten liggen, die elk steeds ook 
geheugenruimte innemen. Efficiënter voor geheugengebruik 
zou het sequentieel allemaal achter elkaar plaatsen van de 
data, maar dit heeft veel nadelen op gebied van kracht, 
efficiëntie en het uitbreiden en krimpen van de data. Omdat 
vandaag de dag het geheugen niet meer duur is, kiest men 
voor de snelle, krachtige en efficiënte manier van werken en 
ziet men niet op het gebruik van enkele bytes meer. 

IV. Message Handling 

Wat niet werd onderzocht maar wat wel hoort bij objecten 
en object georiënteerd werken is “message handling”. Dit 
systeem is erop gebaseerd dat een boodschap als argument aan 
een object wordt gegeven die op zijn beurt beslist hoe deze zal 
reageren op de boodschap. Dit maakt dat er totaal geen 
binding is van de procedures aan een bepaald object. We 
kunnen hierdoor een procedure programmeren die afhankelijk 
van de opgegeven boodschap (die op zich ook een object is) 
andere bewerkingen zal uitvoeren. 

Voor het werken met message handling zijn er heel wat 
voordelen. De belangrijkste is dat een bepaalde boodschap 
naar meer dan één object kan worden gestuurd. Een nadeel 
hieraan is echter dat de compiler hier de programmeur niet 
kan controleren hier zo kunnen serieuze fouten niet 
opgespoord worden, die dan pas bij het effectief uittesten van 
de software aan het licht zullen komen. Zeker indien dit in 
een laat stadium voorkomt kan dit veel tijd en geld kosten, wat 
niet de bedoeling is van een softwareproject: hoe goedkoper, 
hoe beter. 


V. Hoe dit onderzoek is verlopen 

De gegevens in dit artikel zijn samengebracht door 
onderzoek van bestaande informatie op het Internet alsook 
door eigen onderzoek en programmeren op low-level niveau 
in Oberon. Het programmeren en onderzoek gebeurde op 
Microsoft Windows XP Pro en op een Pentium 4. Bij het 
onderzoeken naar de eigenschappen en het voorkomen van 
bepaalde patronen werd dit niet geconcludeerd op 1 of 2 
testen maar door meermaals te onderzoeken, zodat het een 
wetenschappelijke onderhouw heeft (een wetenschappelijk 
experiment moet minimaal 3 maal hetzelfde resultaat geven 
voor je iets mag besluiten). 
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Voor het gebruik van het programmeren op low-level 
niveau is gebruik gemaakt van de module SYSTEM in 
Oberon. De functies SYSTEM.BIT, SYSTEM. ADR, 
SYSTEM.GET, SYSTEM.BYTE, SYSTEM.GET16, 
SYSTEM.VAL, SYSTEM.NEW werden gebruikt in de 
software die de testen uitvoerde. 

De gebruikte informatie van andere gebruikers, docenten of 
programmeurs werd geraadpleegd via het Internet door middel 
van Google of MSN als zoekmachine. 

Verder werd gebruik gemaakt van de module LowLevel die 
ter beschikking werd gesteld door professor dr. F. Arickx van 
de Universiteit van Antwerpen. 


goed voor meer dan 1.000.000 dagelijkse hits en op de nieuwsbrief zijn zo’n 
40.000 inschrijvingen. Deze website eindigde in 2002 ook bij de 10 beste 
Belgische sites, ook weer georganiseerd door Clickx (en Computer Idee). 
Buiten SeniorenNet maakte hij als bijverdienste voor het bekostigen van zijn 
hobby SeniorenNet ook dynamische sites (via databank, scripts en software) 
voor anderen, zoals o.a. voor CECRA en binnenkort ook voor Bond Zonder 
Naam. 

Verder organiseerde hij ook reeds een evenement voor senioren (Our 
Generation genoemd) dat vorig jaar in september plaatsvond in De Schorre te 
Boom, dat meer dan duizend toeschouwers trok. 

Ook schreef hij een boek, ook voor senioren, dat binnenkort (juni) verschijnt 
bij de uitgeverij Lannoo met de titel “Internet na 50”. 

Hij won vorig jaar via zijn school ook de “Heidelandprijs” die georganiseerd 
werd door de Rotaryclub afdeling Heideland tussen de Antwerpse scholen. 
Met zijn eindwerk en presentatie dat verband hield met informatica: Internet 
en veiligheid kreeg hij de eerste prijs. 

Dit alles komt steeds op de tweede plaats, eerst studies, daarna hobby. 

Pascal Vyncke, l c kan Informatica, studentennummer: 20035076. 


VI. Conclusie 

De run-time implementatie van objecten in het Oberon-2 
systeem op het Windows platform is niet zo eenvoudig als 
veel mensen denken. Er wordt rekening gehouden met vele 
aspecten om Oberon efficiënt te laten werken. Een object 
wordt op 3 plaatsen opgeslagen: een pointer naar de 
datastructuur, de datastructuur zelf die pointers bevat naar de 
data en dan tenslotte de data zelf. Bovendien bevat elk object 
ook nog een aantal extra onzichtbare informatie die Oberon 
gebruikt voor het doorverwijzen, voor de garbage collector, 
voor het activeren, enz. 


Met dank aan 

Ikzelf dank de mensen die de bronnen hebben geschreven 
op het Internet alsook professor dr. F. Arickx voor enerzijds 
de lessen waardoor ik dit alles van Oberon ken, maar ook door 
het ter beschikking stellen van een voorbeeldmodule. 
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